OpenAI presenta Pando, el backend de Git en Rust que sostiene su monorepo

OpenAI ha explicado en el artículo «Scaling Git at OpenAI», firmado por Aaron Friel, Taylor Blau y Ted Nyman, cómo ha reconstruido el sistema que sirve Git a su monorepo. El resultado se llama Pando, es un backend escrito en Rust y, según la compañía, ya atiende todo el desarrollo del monorepo con una latencia mediana de push casi un 80 % menor.

Por qué Git dejó de bastar

El detonante fue Codex. Cada ingeniero empezó a empujar más trabajo en paralelo, y los agentes de código, los entornos de desarrollo, los trabajos de investigación y la integración continua multiplicaron ramas, pushes, merges y fetches. A finales de 2025 el sistema empezó a sufrir fetches y pushes lentos, merges fallidos y una fiabilidad que, en algunos momentos, cayó por debajo del 90 %.

La conclusión de OpenAI fue que el límite no estaba en Git, sino en cómo se gestionaba el acceso al repositorio. Por eso mantuvo el protocolo y los clientes de Git y reconstruyó la capa que hay detrás. Ingenieros y agentes siguen usando Git igual que antes.

Cómo funciona Pando

Escrituras: cada push se guarda como un packfile inmutable en almacenamiento de blobs, y cada actualización de rama registra una nueva versión de la referencia en un almacén de metadatos. Dos ramas independientes nunca se esperan: solo compiten los pushes que apuntan a la misma referencia.
Lecturas: en un fetch, Pando compara lo que el cliente tiene y lo que pide, selecciona los packs almacenados que cubren la diferencia y devuelve sus direcciones mediante packfile-uri. El cliente los descarga desde una caché regional con una tasa de aciertos superior al 99 %.
Compactación: los packs pequeños de cada push se fusionan en segundo plano por niveles, al estilo de un árbol LSM, hasta el nivel L4 en el monorepo. Así un cliente que vuelve tras un tiempo no tiene que bajar decenas de miles de ficheros.
Anuncio de referencias: cuando se sube una rama nueva, Pando anuncia solo el tronco. Listar millones de ramas superaría los 100 MiB. El efecto secundario es que las ramas de larga vida reenvían contenido que no es del tronco en cada push; en el monorepo de OpenAI la mediana se mantiene por debajo de 20 KiB.

La consistencia, el precio de escalar

Pando garantiza el orden de las actualizaciones de cada referencia, pero no ofrece una instantánea de todas las ramas en un mismo momento: es consistencia causal. Un cliente que lea varias ramas puede verlas en versiones distintas. OpenAI sostiene que ni las personas ni los agentes dependen de más que del orden por referencia.

Las cifras que da OpenAI

La latencia mediana de push baja casi un 80 %.
Sirve cerca de un petabyte de datos Git al día con pocos núcleos de CPU.
En la hora de mayor tráfico entregó más de 57 TB de packs, más del 99 % desde caché local en disco.
Clones y fetches saturan enlaces de 10 Gbps, incluso en máquinas virtuales estándar.
El push mediano al tronco pesa menos de 20 KiB, y el percentil 99, menos de 3 MiB.

Conviene leerlas con cautela: son datos de la propia compañía, de un único monorepo, y el artículo no da un porcentaje concreto de fiabilidad de merges tras la migración, solo que mejoró. Las comparaciones con protocolos como el commit en tres fases o el registro de escritura anticipada proceden de una simulación que OpenAI describe como modelo didáctico, no de un benchmark de producción.

Diez semanas, Rust y Codex

Según el relato, un ingeniero diseñó el núcleo, los agentes lo implementaron y el equipo lo validó con una batería de pruebas de conformidad frente al comportamiento estándar de Git y una simulación determinista. Los agentes también escribieron especificaciones en Lean y TLA+ para detectar errores. Desde el arranque hasta producción pasaron unas diez semanas, y Pando funciona en producción desde abril de 2026. Arrancó como proxy delante del sistema de control de versiones anterior, sincronizado con él, y las cargas de trabajo se migraron una a una.

¿Se podrá usar fuera de OpenAI?

Pando es interno y no es código abierto; la compañía dice que evalúa cómo compartirlo, sin plazo ni formato. Sí hay trabajo público: las correcciones de las descargas con packfile-uri, una función poco usada del protocolo de Git, han ido al proyecto upstream, y otros cambios de cliente, como la descarga e indexado de packs en paralelo o los «explicit haves» que permiten usar --force-with-lease sin reenviarlo todo, están en la copia de Git de OpenAI en GitHub.

Para el resto de equipos, la lección es que el cuello de botella de un monorepo con muchos agentes escribiendo no tiene por qué estar en Git, sino en el servidor. Si quieres repasar los fundamentos, aquí tienes 18 comandos de Git que todo desarrollador y sysadmin debería dominar, y para el lado del monorepo, Monorepos TypeScript en 2026.

Fuentes: «Scaling Git at OpenAI», OpenAI; resúmenes de This Week in Source Control y Pasquale Pillitteri.